1. Technical Field
The present invention is generally directed to an improved data processing system. More specifically, the present invention is directed to a system and method of providing resource management in association with extensible Java Server Pages.
2. Description of Related Art
Java Server Pages (JSPs) are an extension to the Java servlet technology from Sun Microsystems that allows HyperText Markup Language (HTML) code to be combined with Java code on the same page. The Java provides the processing and the HTML provides the page layout that will be rendered in the Web browser.
JSPs are the primary method in the Java 2 Enterprise Edition (J2EE) platform for displaying dynamic Web pages. Special tags allow Java code to be included on the page as well as inserted into HTML statements without invalidating the HTML syntax. Thus, JSPs let non-Java programmers maintain HTML pages in their favorite authoring programs without interfering with the Java code on the page. With the use of standard and custom JSP tags, the Java code can be completely hidden.
At runtime, the application server turns the JSP into a Java servlet (e.g., .jsp file to .java file) using a JSP translator, which is a part of the servlet container. The servlet is then compiled into bytecode (.class) and run on the server like any other servlet.
Just as a web server needs a servlet container to provide an interface to servlets, the server needs a JSP container to process JSP pages. The JSP container is responsible for intercepting requests for JSP pages and processes these requests in order to provide the JSP pages to the requester.
To process all JSP elements, e.g., directive elements, action elements, and scripting elements, in the JSP page, the container first turns the JSP page into a servlet (known as the JSP page implementation class). The conversion involves converting all template text to println( ) statements and all JSP elements are converted to Java code that implements the corresponding dynamic behavior. The container then compiles the servlet class.
Converting the JSP page to a servlet and compiling the servlet form the translation phase. The JSP container initiates the translation phase for a page automatically when it receives the first request for the page. The JSP container is also responsible for invoking the JSP page implementation class (the generated servlet) to process each request and generate the response. This is called the request processing phase.
FIG. 1 illustrates an example of the phases of execution with regard to processing a request for a JSP from a client computing device. As shown in FIG. 1, a client computing device 110 may send a request for a JSP to a server 120 that includes a JSP container. The server 120 reads the JSP file 125 from a file based I/O system 130 and generates servlet Java code 135 from the JSP file 125. The reading in of the JSP file 125 and the generation of the servlet Java code 135 from the JSP file 125 constitute a translation phase 140 of the processing of the JSP.
Thereafter, the generated servlet Java code 135 is compiled into a servlet class 145 in a request processing phase 150. The server 120 with the JSP container may then execute the servlet class 145 to return the requested JSP content to the client computing device 110.
As long as the JSP page remains unchanged, any subsequent request goes straight to the request processing phase 150, i.e. the JSP container on server 120 simply executes the servlet class file 145. When the JSP page is modified, it goes through the translation phase 140 again before entering the request processing phase 150.
The JSP container is often implemented as a servlet configured to handle all requests for JSP pages. In fact, these two containers, a servlet container and a JSP container, are often combined in one package under the name web container.
Typical JSP containers provide a rigid implementation for the management of Java Server Page resources. Input resources, such as JSP pages, JSP documents, tagfiles and tag library descriptors (TLDs) are expected to be read from file based input/output (I/O) systems. Generated resources, such as the generated source code 135 for the JSP servlet are also expected to be read from/written to file based I/O systems. However, it is sometimes desirable to access resources from other sources other than file based I/O systems.
For example, in WebSphere™, available from International Business Machines, Inc., some JSPs have been required to be able to provide, input sources of JSPs from other sorts of I/O systems, such as relational databases. Typically, in order to provide the ability for a JSP to obtain input from other types of I/O systems, the JSP container code must be manually modified directly. Thus, it would be beneficial to have a system and method for extensible JSP resource management such that the JSP may obtain input from various types of I/O systems without requiring direct JSP container code modification.